Add more context and text around ACK frequency #3706

janaiyengar · 2020-05-28T03:05:33Z

This PR adds explicit context around the choice of ACK frequency in the draft. It also takes in Bob Briscoe's suggestion in #3529, of calling it a guidance in light of the best information we have.

Also does some editorial cleanup of text blocks that were not in the right sections.

martinthomson

This is a little too strong in its current form, I think.

martinthomson · 2020-05-28T03:40:30Z

draft-ietf-quic-transport.md

-forthcoming from the receiver. Therefore, a sender SHOULD ensure that other
-frames are sent in addition to PADDING frames to elicit acknowledgments from
-the receiver.
+The algorithms in {{QUIC-RECOVERY}} are resilient to receivers that do not


do we want to add "generally" to "resilient"? Or, "in principle"? Or "in theory"?

draft-ietf-quic-transport.md

martinthomson · 2020-05-28T03:43:51Z

draft-ietf-quic-transport.md

+A receiver determines how frequently to send acknowledgements in response to
+ack-eliciting packets. Under normal circumstances, reducing the frequency of
+acknowledgement packets can improve connection and endpoint performance in
+several ways, such as reducing computational cost at both endpoints, and
+improving connection throughput on severely asymmetric links.


You need to phrase this more as a trade-off. This is concentrated on the benefits of reducing acknowledgments. But the introduction here also needs to recognize that generating acknowledgments in a timely fashion is critical for performance.

martinthomson · 2020-05-28T03:44:49Z

draft-ietf-quic-transport.md

+several ways, such as reducing computational cost at both endpoints, and
+improving connection throughput on severely asymmetric links.
+
+However, there are undesirable consequences to a receiver simply reducing the


If you balance the first paragraph out, then you don't need a "however" here. You can just talk in more detail about the advantages of more frequent acknowledgment.

martinthomson · 2020-05-28T03:48:14Z

draft-ietf-quic-transport.md

+acknowledgement frequency, especially to an arbitrary fixed value. A sender
+relies on receipt of acknowledgements to determine the amount of data in flight
+and to detect loss; see {{QUIC-RECOVERY}}. Loss detection can be delayed with
+late acknowledgements. Window-based congestion controllers, such as the one
+defined in {{QUIC-RECOVERY}}, rely on receipt of acknowledgments to increase
+their sending rate. Consequently, a connection can suffer performance penalties


If you move the general statement at the end of this to the first paragraph, then you can probably shorten this paragraph to:

Endpoints rely on timely acknowledgment to detect loss; see Section X of {{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in Section X of {{QUIC-RECOVERY}} rely on acknowledgments to manage their sending rate. In both cases, delaying acknowledgment can adversely affect performance.

We don't need the specific dig regarding the "arbitrary fixed value".

martinthomson · 2020-05-28T03:55:29Z

draft-ietf-quic-transport.md

+Further research and experimentation will yield effective mechanisms to balance
+this tradeoff. Meanwhile, this document provides the following guidance:
+{{sending-acknowledgements}}, a receiver SHOULD generate an ACK frame for at
+least every second ack-eliciting packet. This recommendation is in keeping with


A receiver SHOULD send an ACK frame after receiving at least two ack-eliciting packets. Better knowledge of network conditions or further research and experimentation might suggest alternative acknowledgment strategies with better performance characteristics. This recommendation is general in nature and consistent with recommendations for TCP endpoint behavior {{?RFC5681}}.

draft-ietf-quic-transport.md

Co-authored-by: Martin Thomson <mt@lowentropy.net>

martinthomson

Thanks! This appears to be much better. And it points in the right direction without being overly prescriptive.

draft-ietf-quic-transport.md

martinthomson · 2020-05-28T23:51:49Z

draft-ietf-quic-transport.md

+packets. Better knowledge of network conditions or further research and
+experimentation might suggest alternative acknowledgment strategies with better
+performance characteristics. This recommendation is general in nature and
+consistent with recommendations for TCP endpoint behavior {{?RFC5681}}.


I think maybe we can swap the last two sentences, so that "this recommendation" is better bound to the first sentence.

martinthomson · 2020-05-28T23:52:27Z

draft-ietf-quic-transport.md

+control purposes {{QUIC-RECOVERY}}. Sending only PADDING frames might cause the
+sender to become limited by the congestion controller with no acknowledgments
+forthcoming from the receiver. Therefore, a sender SHOULD ensure that other
+frames are sent periodically in addition to PADDING frames to elicit acknowledgments from


Check line length.

ianswett

This seems to be heading in a good direction, thanks for working on it.

ianswett · 2020-05-29T01:00:50Z

draft-ietf-quic-transport.md

+Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.


Suggested change

Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending

rate. In both cases, delaying acknowledgment can adversely affect performance.

Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to open up congestion window,

allowing more packets to be sent, as well as increase the congestion window. In both

cases, delaying acknowledgments can adversely affect performance.

ianswett · 2020-05-29T01:02:31Z

draft-ietf-quic-transport.md

+Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
+rate. In both cases, delaying acknowledgment can adversely affect performance.
+
+On the other hand, reducing the frequency of acknowledgement packets reduces


Do you mean ACK-only packets? Otherwise this could be read to include ACK frames bundled with data, which I don't believe is the intent.

draft-ietf-quic-transport.md

ianswett · 2020-05-29T01:11:57Z

draft-ietf-quic-transport.md

+packets. Better knowledge of network conditions or further research and
+experimentation might suggest alternative acknowledgment strategies with better
+performance characteristics. This recommendation is general in nature and


Suggested change

packets. Better knowledge of network conditions or further research and

experimentation might suggest alternative acknowledgment strategies with better

performance characteristics. This recommendation is general in nature and

packets. Knowledge of how frequently the peer's congestion controller needs feedback,

network conditions or further research and experimentation might suggest alternative

acknowledgment strategies with better performance characteristics. This

recommendation is general in nature and

Co-authored-by: Martin Thomson <mt@lowentropy.net> Co-authored-by: ianswett <ianswett@users.noreply.github.com>

janaiyengar · 2020-05-29T05:54:22Z

Thanks @ianswett @martinthomson -- comments incorporated.

draft-ietf-quic-transport.md

ianswett · 2020-06-01T00:50:09Z

draft-ietf-quic-transport.md

+
+Endpoints rely on timely acknowledgment to detect loss; see Section 5 of
+{{QUIC-RECOVERY}}. Window-based congestion controllers, such as the one in
+Section 6 of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending


I would still like to be clearer here and I don't really like "sending rate" in the context of window-based controllers. I made some specific suggestions before. Can you take another look at them?

It's still quite accurate, IMO. Ultimately, increasing the congestion window increases the sending rate. That is the higher order point here -- that reducing ack frequency reduces the throughput of the sender.

I've changed it to "manage their congestion window"

Thanks, I think that's better, but I also think it doesn't highlight a key point, which is if a receiver delays sending an ACK for Xms, the sender may be blocked from sending for Xms.

Except for slow start, I don't think the congestion window itself is the issue, but rather the available congestion window.

draft-ietf-quic-transport.md

Co-authored-by: ianswett <ianswett@users.noreply.github.com> Co-authored-by: Martin Thomson <mt@lowentropy.net>

draft-ietf-quic-transport.md

Co-authored-by: ianswett <ianswett@users.noreply.github.com>

Add more context and text around ACK frequency

f1fb3b5

janaiyengar added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels May 28, 2020

janaiyengar requested review from martinthomson and ianswett May 28, 2020 03:05

janaiyengar mentioned this pull request May 28, 2020

Changing the Default QUIC ACK Policy #3529

Closed

martinthomson reviewed May 28, 2020

View reviewed changes

janaiyengar and others added 2 commits May 28, 2020 16:27

Apply suggestions from code review

2f2fc2a

Co-authored-by: Martin Thomson <mt@lowentropy.net>

mt's excellent suggestions

9e6d2f1

martinthomson approved these changes May 28, 2020

View reviewed changes

ianswett reviewed May 29, 2020

View reviewed changes

janaiyengar and others added 2 commits May 28, 2020 22:43

Apply suggestions from code review

f1d6260

Co-authored-by: Martin Thomson <mt@lowentropy.net> Co-authored-by: ianswett <ianswett@users.noreply.github.com>

ian/mt comments

e34dcf8

kazuho approved these changes May 29, 2020

View reviewed changes

martinthomson approved these changes May 31, 2020

View reviewed changes

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved

ianswett reviewed Jun 1, 2020

View reviewed changes

janaiyengar and others added 2 commits May 31, 2020 19:32

Apply suggestions from code review

12b886d

Co-authored-by: ianswett <ianswett@users.noreply.github.com> Co-authored-by: Martin Thomson <mt@lowentropy.net>

s/sending rate/congestion window

3c9f342

marten-seemann approved these changes Jun 1, 2020

View reviewed changes

ianswett reviewed Jun 1, 2020

View reviewed changes

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved

janaiyengar and others added 2 commits May 31, 2020 23:24

Apply suggestions from code review

76af223

Co-authored-by: ianswett <ianswett@users.noreply.github.com>

reflow

3bbb568

ianswett approved these changes Jun 1, 2020

View reviewed changes

janaiyengar merged commit b3ea75a into master Jun 1, 2020

janaiyengar deleted the jri/ackf branch June 1, 2020 23:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add more context and text around ACK frequency #3706

Add more context and text around ACK frequency #3706

janaiyengar commented May 28, 2020

martinthomson left a comment

martinthomson May 28, 2020

martinthomson May 28, 2020

martinthomson May 28, 2020

martinthomson May 28, 2020

martinthomson May 28, 2020

martinthomson left a comment

martinthomson May 28, 2020

martinthomson May 28, 2020

ianswett left a comment

ianswett May 29, 2020

ianswett May 29, 2020

ianswett May 29, 2020

janaiyengar commented May 29, 2020

ianswett Jun 1, 2020

janaiyengar Jun 1, 2020

janaiyengar Jun 1, 2020

ianswett Jun 1, 2020

		Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
		rate. In both cases, delaying acknowledgment can adversely affect performance.

-Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to manage their sending
-rate. In both cases, delaying acknowledgment can adversely affect performance.
+Section X of {{QUIC-RECOVERY}}, rely on acknowledgments to open up congestion window,
+allowing more packets to be sent, as well as increase the congestion window. In both
+cases, delaying acknowledgments can adversely affect performance.

Add more context and text around ACK frequency #3706

Add more context and text around ACK frequency #3706

Conversation

janaiyengar commented May 28, 2020

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar commented May 29, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment